Shareware Grab Bag/Shareware Grab Bag.iso/090/dv_info.arc/DVSTUP.THD

Text File | 1986-03-29 | 21KB | 522 lines

@*
As members of the SIG began to receive and install DesqView in their systems,
various questions arose about the proper setup of the program.  Topics
discussed in this file include the use of XDV.COM, batch files, allocation of
memory to particular windows, and the use of PIF files and the XX-LOAD files
supplied by DV.  Each subtopic is prefixed by the @* symbol.


@* XDV.COM

Fm: Earle Robinson 70135,141
To: Michael Rothman 74405,1313 (X)

Are you using dv with the xdv.com program on an at so that about 60-70k gets
shoved up to rampage, freeing more memory <640k, on an AT?


Fm: Michael Rothman 74405,1313
To: Earle Robinson 70135,141 (X)

Yes, I load DESQview by running xdv.com.  As I understand it, that causes dv to
load using some space between 640k and 1M, leaving more room in the lower 640k
range.  The result is that I have about 60k or 65k more room for windows in the
lower 640k before moving into expanded memory.  Nice little trick.  How is dv
working for you?


Fm: Earle Robinson 70135,141
To: Michael Rothman 74405,1313

Several problems, mostly due to a defective version of dv, now being replaced.
Seems that so-called newer AT's don't like xdv.com & the newer version is
supposed to fix that.  However, I have to assume that almost all AT's out there
are 'newer' since mine was delivered in October '84, a scant 2 months after the
announcement of the machine.  Not using xdv.com permits me to use the defective
version and I am, for the moment, not all that impressed.  Among other
complaints is the fact that the ansi.sys used by dv is a subset of the ibm
subset of the full set.  So, it is pretty weak, indeed.  Once I get the newer
version, I'll experiment a little more.


Fm: Earle Robinson 70135,141
To: Norm Lew 70047,3340 (X)

Screen goes blank or there is a carriage return and the cursor sits at the
beginning of the next line.  In either case, the system is hung and requires a
cold boot.  I tried removing all tsr's and even ansi.sys, but the results were
the same.


Fm: Norm Lew 70047,3340
To: Earle Robinson 70135,141 (X)

When you installed DV 1.2, did you install it over the earlier version or did
you clear out the directory before installation? My recollection is that the
command that starts DV 1.2 is looking for either a .com file or an .exe file
and is finding the wrong one. I think I had the same problem. If you haven't
found the problem before I get back this evening, I'll look further......Norm


Fm: Earle Robinson 70135,141
To: Norm Lew 70047,3340

Good question.  I cleared out the sub-directory and then installed 1.2.  After
finding that it hung after typing 'dv', I tried removing all trs's and
rebooting.  Tried again, also w/o success.  Then, to make certain, I copied all
the files from the quarterdeck diskette onto a ramdisk, added command.com, and
tried once again.  Same result.   Perhaps a defectived master diskette?  I
don't know.


Fm: Earle Robinson 70135,141
To: all

The problem is resolved.  I received a defective version of desqview, the one
dated 12-09-85.  It seems that there is phantom rom below the real rom in high
memory on the AT, and dv was trying to load there.  I was told that I could
still use it for a while until receiving my replacement diskette by removing
'dv.com', the sole purpose of which is to put circa 70k of code in expanded,
i.e. rampage memory.  It is 'dv.exe' which is the actual program.  I only wish
that Saxer, or someone else from desqview had put up a warning about this and
thus saved me a lot of time trying to verify that my system was not at fault.

I have now installed it, but have some problems, mainly using list.com and due
to the fact that the 'type' command doesn't work.  Also, their own ansi driver,
which overlays the dos one, doesn't recognize as many control stuff.  I am also
chagrined to note that the system is slowed down under dv.


Fm: Earle Robinson 70135,141
To: Conrad Kageyama (Sysop) 76703,1010 (X)

The version I have doesn't run on so-called newer at's.  Well, my at dates from
oct 84, not actually hot off the production line.  I'd have to assume that most
at's are therefore 'new'.  Then, I spoke to Gary Saxer this evening.  He was
somewhat more guarded and claimed the version wasn't defective; it just didn't
work on most at's!  Well, I do have it running now, after deleting dv.com,
which means I have 60k less ram since that program puts about that much in
rampage.  I've found that using 'type' to get at a program on another disk
doesn't work, though if one is on the disk, and in the directory, it does.  I
also note some degradation of speed, even on the at.  Finally, their
implementation of ansi.sys is a subset of ibm's subset of it, thus not very
exciting.


Fm: Clyde Washburn 70305,1211
To: Conrad Kageyama (Sysop) 76703,1010 (X)

Well, QD did decide to sent me a DV update (dated 1/10/86), but the xdv.com
loader that's supposed to get 70k of code into eems mem still causes my AT to
hang when DP is selected. I've gone back to DoubleDOS -- it is more solid at
the moment, and faster. Now, does anyone out there understand ems well enough
to tell me how to map a 64k seg to the A000 block, so I can give DD a bit more
headroom?


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Clyde Washburn 70305,1211 (X)

I don't mean to laugh, but it looks like QD and AST are out to get you or
sumthin'...<grin>...  No problems at all loading XDV in my PC, and the MS
program is very nice for telling you what you've got left to work with...


Fm: Earle Robinson 70135,141
To: Conrad Kageyama (Sysop) 76703,1010 (X)

No, it isn't washburn, but the different machines.  There is apparently no
problem with the pc; it is only with the at.


Fm: Clyde Washburn 70305,1211
To: Earle Robinson 70135,141 (X)

They seem to be a bit confused! My 12/9 did as yours, they then gave me the
same rename advice, and said versions after 12/20 were fixed. When I asked for
an update I never got a straight "yes". When a disk did arrive, it was obvious
it was at least 2 revs later, being dated 1/10/86 -- but alas their problem
must be more pervasive than they first appreciated as one of the install
messages now mentions xdv and says it MAY work on SOME computers (no list). All
seemed to be well with xdv until I attempted to Delete Programs -- each and
every time the machine locked up so tight it was BOS time. It's a shame DD
won't support EEMS (or EGA), as it does everthing I want, namely adding a
return-to-dos capability to pgms that don't have that provision. BTW, it was
pretty easy to map 64k to the A000 block, using the EMS spec for int 67 calls,
but I've not yet figured how to get dos to recognize the extra 64 without
reloading remm.sys and hanging the process. Hope dos 4.0 is close.


Fm: Earle Robinson 70135,141
To: Clyde Washburn 70305,1211

In other words, the xdv.com works, except to delete programs.  Have you
reported this to them?  Obviously, you could exit dv, and reload without
xdv.com to do the deletion of the programs (assuming you mean deletion of
programs within dv), but that is a hassle.


Fm: Clyde Washburn 70305,1211
To: Earle Robinson 70135,141 (X)

What's happening is trying to jam more than 64k of code into 64k, on the AT
(only). See my messages to "all" for the necessary patches to the version of
1/10. It is obvious they NEVER ran the fixed version on an AT, 'cause the
problem is generic -- ALL AT's have the E000 block mapped to ROM sockets.


Fm: Clyde Washburn 70305,1211
To: all

There are 2 bugs in the DESQview version of 1/10/86:
a) XDV.COM avoids the E000-EFFF bank on the the AT as it should (that bank is
mapped to ROM sockets), but it insists on trying to find 5-16k segments above
D000! If allowed to start at the lowest available seg (C000, or C800 with EGA)
all is OK.
b) DVMG.COM does not always correctly detect a Hercules compatible board in an
AT, as a timing count is too small.
There is also a bug in REMM.SYS, V2.80 on the AT -- it reports the E000EFFF
bank as available, and it is NOT. Add /X=E000-EFFF to you REMM.SYS entry to
prevent any problems with other software.

Debug Scripts:

debug xdv.com
-a 916
xxxx:916 jmp B0A
xxxx:919 <CR>
-a B0A
xxxx:B0A cs: cmp byte ptr [8DC],0
xxxx:B10 jnz B18
xxxx:B12 sub cx,+4
xxxx:B15 jmp 919
xxxx:B18 jmp 91C
xxxx:B1B <CR>
-rcx
A0A:A1B
-w
-q
debug dvmg.com
e 270
40.00 00.02 xx.<CR>
-w
-q


Fm: Paul Ferrara 70075,252
To: Gary Saxer (Quarterdeck) 73206,564

What does xdv.com do?  Doesn't seem to make any difference on my system (XT
w/RAMpage).


Fm: Earle Robinson 70135,141
To: Paul Ferrara 70075,252

Ah, another poorly documented feature.  XDV.com is to load part of dv into
rampage memory.  It will give you about 60-70k more memory in the lower 640 as
a result.  The version on the 1/10/86 release has a nasty bug which is swatted
with a patch in dl0.  Reportedly, there is never any problem using xdv.com on
an xt w/ rampage.  However, on the at, there have been problems though I have
found it to work.  If by chance it doesn't, enter dv typing 'dv' rather than
'xdv'.


@* ANSI.SYS

Fm: Michael Rothman 74405,1313
To: Earle Robinson 70135,141

I'm interested in your comment about the dv implementation of ansi.sys.  Just
which ansi.sys functions do we give up under dv?  I've not noticed any loss of
functionality, but then I'm not a big user of those functions anyway!


Fm: Gary Saxer (Quarterdeck) 73206,564
To: Michael Rothman 74405,1313

I believe that the only function mentioned in the DOS manual which DESQview
does not implement are the "keyboard keys" ones.  They are not "true" ANSI but
extensions.


Fm: Earle Robinson 70135,141
To: Michael Rothman 74405,1313

First, you can't redefine the keyboard with dv's ansi.  I like to define some
like ^Q to clear the screen, alt-c to put 'copy ' on the screen, etc.
Secondly, you can't even use the ansi if you exit from a program within a
window into dos.


Fm: T. B. Eyrick 72446,317
To: Earle Robinson 70135,141

Have you tried Fansi with DV?


@* BATCH FILES

Fm: Norm Lew 70047,3340
To: Jim Butler 74766,1460

If you start ATO with a batch file, and include "exit" as the last command,
your DV window will close upon exiting ATO with the "X" key.


Fm: Jim Butler 74766,1460
To: Norm Lew 70047,3340

But, don't I want the window to close on exit to DOS?  The DV manual says you
need the "exit" in your batch file to do that.


Fm: Norm Lew 70047,3340
To: Jim Butler 74766,1460

If you use batch files to open the window, DV thinks that every command is an
exit to DOS and closes the window.  Hence turn off the option and include an
exit command.


Fm: Gary Saxer (Quarterdeck) 73206,564
To: Jim Butler 74766,1460

Right exactly as Norm says:  if you want a batch file to work you should have
"Close on Exit" set OFF and then put an EXIT at the end of your batch file.


Fm: Jim Butler 74766,1460
To: Norm Lew 70047,3340 (X)

Norm, Sorry ... I still am not following .. when do I want to have have exit in
my batch files ... and when do I want to exit to dos on closing window by
option selection???


Fm: Steve Kalman 75136,360
To: Jim Butler 74766,1460

I have ato running directly from DV (no batch file) and it automatically closes
on exit to DOS.


Fm: Jim Butler 74766,1460
To: PETER MCKINNEY 74166,1301 (X)

The best way to answer your question on batch files is to give you and example
or two (with DV's super cut and paste, which I will use to call up the batch
file in the #8 dos window, mark, and transfer to this #5 window). So, here is
my lotus batch file:
c: cd \sk c:\sk\key c:\123 /ml cls cd \l search c:\l;c:\123; C:\DV\lt-load.com
123.exe exit
You can individually set the environment for each window program. why should I
give up memory for lotus' window to sidekick, turbo lightning, etc which *I*
may not use in lotus. I only want superkey available (and if dv improves its
macro capacity, I would dearly LOVE to give up superkey for the DV macro
capacity). On the other hand, I want turbo lightning's spell checker in ato,
wordstar, and kedit (not rbase, dos windows, etc), and so on and so on. So each
window is presently configured with its own batch file, and a global macro (the
!) sets up all my windows for me automatically ...


Fm: Norm Lew 70047,3340
To: Don Singleton 76154,26

By the way if you use batch files to open a window, make sure you turn off the
"Close on exit to DOS" option in the CP module. It's turned off when it's not
highlighted. If you don't do this, you'll get dumped everytime you try to open
the window. Put an "exit" command in your batch file and the window will close
when you exit the program.


Fm: Earle Robinson 70135,141
To: Gary Saxer (Quarterdeck) 73206,564

Do you plan to offer a way for people to easily make their own xx-load.com
programs?   Why not release the source for them?


Fm: Gary Saxer (Quarterdeck) 73206,564
To: TODD FLADEN 76555,643

First make sure that you have told DESQview (by running SETUP inf the \DV
directory), that you display uses more than 2 colors.  Answer Y to the second
question during "Simple Setup".  That is probably what is wrong.  Please note
that DV will not be able to save multiple colors when a graph is displayed in
enhanced mode.  Only black & white will survive because DV only save the first
16K of video memory, and then only when "Displays Graphics" is on.


Fm: Norm Lew 70047,3340
To: Jim Butler 74766,1460

If you use a batch file to open a window, and you wish the window to close when
you exit the program, then put "exit" in your batch file and turn off the
"Close on exit to DOS" option in the CP module.

If you do not use a batch file, and you wish the window to close upon exiting,
then leave the "Close on exit to DOS" option on.

Try leaving the option on and open a window with a batch file and see what
happens.


Fm: Gary Saxer (Quarterdeck) 73206,564
To: Jim Butler 74766,1460

Perhaps you should check out DESQview's scripts.  They often remove the need
for batch files, and take up a lot less space on disk.  Just a suggestion of
course, one of the nice features of DV is that you can still use batch files if
you want.


Fm: Jim Butler 74766,1460
To: Gary Saxer (Quarterdeck) 73206,564

Help me out here a little.  I am using global script that presently sets up 9
windows for me.  Most of them call up batch files, zoom windows, etc.  I am not
using the learn feature for any windows, though I understand there is that
feature available.  So how would I usse the learn macros of a window to replace
a bat file?  (assign the bat file to alt-x?) and how could one macro call the
other? alt c just contains the alt x command?  What is the chance of
strengthening the macro facility to (1) permit at least 1 auto macro per
window?  Superkey permits 1 auto per macro set, and is contemplating letting
more than 1 be called formt he command line.  Prokey 4.0 will permit unlimited
auto macros.  (2) make the editing facility automatic or easier ...  Prokey 4.0
is the easiest with INSTANT editing, loading, re-execution, saving, etc with
only 1 keystroke per function, and "sticky menus".

Also, How about a back scrolling function which lets you store the past screens
in a memory buffer and call them back with a scrolling feature?


Fm: PETER MCKINNEY 74166,1301
To: Jim Butler 74766,1460

In an earlier message, you mentioned "BATch files to set up the environment for
each window" .  Could you provide an explanation of what you meant, please ?


@* RAM ALLOCATION WITHIN WINDOWS

Fm: Steve Kalman 75136,360
To: Conrad Kageyama (Sysop) 76703,1010 (X)

Connie, I've noticed that I had to crank up the RAM allocation on every file
that DV auto-installed. It has become a regular part of the install for me now.


Fm: Gary Saxer (Quarterdeck) 73206,564
To: Steve Kalman 75136,360

I have been very frugal with the memory allocations for programs in DESQview
(not everyone has a RAMpage you know!).  The sizes are meant to be adequate to
run.  Perhaps you should check Appendix D under "Installing more than one copy
of the same program".  I had that added so that you could have multiple copies
of, say 1-2-3, each with a different memory size.  I suggest that you put the
size in the title so you can tell each of them on the Open Menu.


Fm: Michael Rothman 74405,1313
To: Gary Saxer (Quarterdec 73206,564

Good point about putting the window size in the title to help keep track of
memory.  I've been doing that for some time.  A better solution would be for dv
to display window size in the open window menu.  Can that be placed on the dv
"wish list".


Fm: Gary Saxer (Quarterdeck) 73206,564
To: Paul Ferrara 70075,252

DESQview resets several key interrupts every time a program returns to
"command" level.  We must do this in order for some programs to work right.  So
loading another COMMAND.COM "raises" the command level by 1 and prevents us
from resetting the interrupts.  In effect, DV thinks that COMMAND is the
program running.  We decided that since this workaround exists we would use
this method rather than have some programs not work at all.  Yes I can explain
window sizes.  Let's start with the second Q first.  DV uses all the memory
from the end of the program to the top of memory in which to run programs.
However, it con only "page" (have RAMpage move it quickly away that is) the
area where RAMpage is supplying the physical memory.  Thus the very first
program you run can be the biggest because it includes "motherboard" memory and
RAMpage memory.  The others can only be in RAMpage memory as long as you don't
want to swap.  Remember that you can have 9 windows at max size but they will
swap each other to disk.  Now you should see that the RAMpage area cannot
include the 1 page (16K max) in which the beginning of the program area starts
because part of DV code is there too and can never be swapped.  Try setting
your switches to 64K and watch wat happens.  Also be sure to run XDV.


@* XX-LOAD.COM

Fm: Earle Robinson 70135,141
To: Conrad Kageyama (Sysop) 76703,1010 (X)

I have never seen a cogent explanation of what those xx-load.com files actually
accomplish.   Do you know?  I couldn't find any explanation in the manual,
which also lacks quite a few other things.  Pity that they don't have a good
technical appendix somewhere there.  I remember the other day when saxer said
that there was no explanation for the rather cryptic fast comm option on the dv
menu, saying it wouldn't interest most people!   Unfortunately for quarterdeck,
its program doesn't suit most people right now because of one of the following
reasons:
don't know of it
don't understand what it does
don't have an expanded memory board
The main market of desqview at present is precisely not 'most' people.  It is
the so-called poweruser segment which IS interested in such information.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Earle Robinson 70135,141 (X)

A cogent explanation???... no... but from fooling around here and there, it
looks like the xx-load.com programs for the most popular applications that are
normally not well-behaved write PIF-like DVP files so that those programs can
be run in a small window in the background....


Fm: Paul Ferrara 70075,252
To: Earle Robinson 70135,141 (X)

Your assumption makes sense.  But I've found that other than a large window for
Kedit and a slightly smaller one for dBase III, the rest of the windows are
considerably smaller in size.  So I'd normally have 5-6 windows open and had
enough extra to feel comfortable creating a 360K ram disk and a 64K spooler.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Paul Ferrara 70075,252

oh, oh, am I goofing???...  I didn't see any mention of moving the PIF file
from the program's subdirectory to the DV directory...  I would imagine that DV
would find it though, since the DV directory is on the main PATH and you set
the data-path in the configuration...  I've not *run* XTALK, but it does come
up in a small window, so I *assume* that it's found the PIF file okay..


Fm: Paul Ferrara 70075,252
To: Conrad Kageyama (Sysop) 76703,1010 (X)

You're right.  The .pif file should be in the program's sub-directory.


Fm: Michael Rothman 74405,1313
To: Earle Robinson 70135,141

As Connie has already indicated, the xx-load.com programs for popular
applications which are not will behaved, are loaders which allow the programs
to work properly in small windows.  For example, I'm able to run 1-2-3 in a
small window at this moment, as I'm writing this message.


Fm: Jim Butler 74766,1460
To: Paul Ferrara 70075,252 (X)

Paul, What is the "so what?" of having the pifs in the DV directory instead of
the program being called?  I have been doing just that, and hadn't noticed any
untoward effects ... will programs load faster?